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Abstract 

This  paper  presents  a  polymorphic  extension  to  a  type  system  that  prevents  the  misuse  of  object 
protocols.  Polymorphism  allows  classes  to  be  generic  in  the  Access  Permissions  in  their  specifica¬ 
tions.  Access  Permissions  describe  both  the  current  state  of  an  object  and  whether  or  not  references 
to  the  object  alias.  Polymorphic  Access  Permissions  allow  programmers  to  specify  certain  patterns 
that  we  have  encountered  in  practice,  for  example  a  collection  of  open,  unaliased  files.  This  paper 
also  describes  an  implementation  of  this  system  as  a  static  typestate  checker  for  the  Java  program¬ 
ming  language. 


1  Introduction 


This  paper  presents  a  type  system  and  a  related  implementation  for  a  language  that  prevents  the 
misuse  of  object  protocols.  Such  systems  are  generally  known  as  typestate  checkers.  The  novel 
feature  of  this  language  is  that  its  type  system  supports  parametric  polymorphism  over  Access  Per¬ 
missions,  thereby  addressing  a  key  limitation  of  the  type  system  upon  which  it  directly  builds  [2]. 
We  are  unaware  of  any  other  static  typestate  checker  that  supports  a  similar  level  of  expressiveness. 

In  practice,  many  classes  in  object-oriented  programs  define  protocols.  The  protocols  pro¬ 
hibit  certain  methods  of  a  class  from  being  called  at  certain  times,  generally  depending  on  the 
state  of  class  instances.  To  take  a  common  example,  consider  Java’s  Iterator  interface.  The 
next  method  on  an  iterator  should  only  be  called  if  there  are  actually  elements  left  to  iterate  over, 
otherwise  the  call  will  result  in  a  run-time  exception.  While  classes  may  frequently  define  such 
protocols,  popular  languages  generally  do  not  check  that  these  protocols  are  obeyed.  As  a  re¬ 
sult,  there  has  been  considerable  work  in  the  research  community  on  static  and  dynamic  typestate 
checking  [13,  8,  11,  7]. 

Of  the  approaches  that  attempt  to  check  protocol  usage  statically,  the  subset  that  work  modu- 
larly,  checking  each  method  once  like  a  traditional  type  system,  must  somehow  deal  with  aliasing. 
When  tracking  an  object’s  state  as  it  steps  through  a  method  body,  the  potential  for  unrestricted 
aliasing  means  that  any  method  call  might  potentially  alter  the  state  of  that  object  through  hidden 
references.  Typestate  checkers  typically  deal  with  this  problem  by  imposing  aliasing  restrictions 
such  as  uniqueness  [7,  8].  This  paper  builds  on  the  work  of  Bierhoff  and  Aldrich  [2]  who  intro¬ 
duced  the  notion  of  Access  Permissions  for  tracking  object  states  and  aliasing.  Access  Permissions 
associated  with  program  references  track  not  only  the  state  of  the  object  referenced,  but  the  per¬ 
mission  available  to  modify  that  object  and  potentially  held  by  other  references.  This  permission 
information  is  encoded  in  one  of  five  permission  kinds ,  recapped  in  Figure  1,  which  greatly  in¬ 
creased  the  flexibility  of  aliasing  when  compared  with  existing  approaches. 


This  Ref.  May: 

Other  Refs.  May: 

No  Other  Refs.  Read 

Write 

Read 

unique 

immutable 

pure 

Write 

unique 

full 

share 

Figure  1:  The  five  permission  kinds 


Polymoprhism  over  Access  Permissions  is  important  for  many  of  the  same  reasons  that  para¬ 
metric  polymorphism  is  already  useful  in  standard  type  systems;  it  increases  the  precision  of  the 
type  system  for  types  whose  implementations  are  in  some  sense  “ambivalent”  about  the  objects 
they  reference.  In  Java  1.5  we  can  use  this  feature  to  define  a  class  Stack<T>,  a  stack  that  can  hold 
elements  of  any  type.  When  that  class  is  instantiated  with  some  type,  say  File,  we  are  ensured 
that  that  particular  instance  will  only  accept  and  return  files. 

In  our  case,  Access  Permissions  statically  describe  the  current  state  of  an  object  reachable 
through  a  reference,  and  whether  or  not  that  reference  may  be  aliased  by  other  references.  By 
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enabling  polymorphism  over  Access  Permissions,  programmers  can  write  classes  that  are  ambiva¬ 
lent  about  their  elements’  protocols  and  level  of  aliased-ness.  For  example,  the  same  Stack<T> 
class  can  be  given  polymorphic  specifications.  Later  on,  a  stack  can  be  instantiated  in  a  variety  of 
different  ways,  say  a  stack  of  unique  pointers  to  open  files,  or  a  stack  of  shared  pointers  to  sockets 
guaranteed  to  be  open. 

To  give  a  clearer  picture  of  the  difficulties  that  arise  without  polymorphism,  we  will  attempt  to 
specify  just  such  a  stack  using  our  existing  methodology  [2].  Figure  2  shows  the  implementation 
and  specification  of  a  mutable  stack.  This  stack  defines  only  two  methods,  push  and  pop.  If  pop 
is  called  when  the  stack  is  empty,  it  simply  returns  null.  The  stack  defines  no  protocol  of  any 
interest,  but  since  it  is  generic  in  the  types  of  the  elements  it  holds,  its  elements  very  well  might. 

1  ©Invariants (©State (name=" alive " ,  inv="unique (first)  in  alive")) 

2  class  Stack<T>  { 

3  ©Invariants (©State (name=" alive " , 

4  inv="unique (next)  in  alive  *  pure(item)  in  alive")) 

5  class  Node  {  T  item;  Node  next;  } 

6  Node  first ; 

7 

8  ©Spec (post="unique (this)  in  alive") 

9  Stack()  {  first  =  null;  } 

10 

11  ©Spec  (pre  =  "unique  (this)  in  alive  *  pure(item)  in  alive", 

12  post="unique (this)  in  alive") 

13  void  push(T  item)  {  Node  n  =  new  Node () ; 

14  n.item  =  item;  n.next  =  first; 

15  first  =  n; 

16  } 

17 

18  ©Spec (pre="unique (this)  in  alive", 

19  post="unique (this)  in  alive  *  pure(result)  in  alive") 

20  T  pop()  { 

21  if(  first  ==  null  )  return  null; 

22  else  {  T  result  =  first. item; 

23  first  =  first. next;  return  result; 

24  } 

25  } 

26  } 

Figure  2:  A  specification  of  a  Stack  class,  without  polymorphism.  It  is  weak  in  the  sense  that  no 
matter  what  state  the  elements  of  the  stack  are  in,  the  caller  of  pop  method  only  knows  the  element 
are  in  the  “alive”  state. 

We  have  attempted  to  specify  this  stack  in  as  general  a  way  as  possible.  Because  the  implemen¬ 
tation  does  not  constrain  the  types  of  the  elements  it  holds,  it  also  does  not  constrain  the  protocols 
defined  by  those  elements.  If  a  programmer  only  pushes  open  files  on  the  stack,  he  expects  open 
files  to  be  returned  from  the  stack.  Furthermore,  for  verification  purposes,  the  implementation  does 
not  constrain  the  permission  kind  associated  with  those  elements.  In  other  words,  any  permission 
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that  the  caller  of  the  push  method  is  willing  to  forfeit  to  the  pushed  item,  can  soundly  be  trans¬ 
ferred  to  the  eventual  caller  of  the  pop  method.  For  these  reasons,  the  Access  Permissions  to  the 
stack  elements  (highlighted  in  bold)  in  Figure  2  are  as  general  as  possible:  the  element  must  be 
in  the  “alive”  state  (trivially  satisfied  by  every  object)  and  the  element  must  have  pure  permission 
kind  (satisfiable  with  any  other  permission  kind). 

Unfortunately,  this  specification  is  quite  imprecise.  While  it  is  easy  to  satisfy  the  pre-condition 
of  the  push  method  (line  1 1),  for  any  object,  the  post-condition  of  the  pop  method  (line  19)  is  quite 
weak.  For  example,  for  a  stack  of  type  Stack<File>,  even  if  we  push  an  open  file,  and  the  calling 
site  has  the  sole  reference  to  that  file  f  (signified  by  the  Access  Permission,  unique(f)  in  Open), 
we  lose  all  this  information  when  calling  the  pop  method.  The  caller  of  the  pop  method  receives  a 
permission  to  read  but  not  modify  a  file  that  may  be  open  or  closed  (pure(result)  in  Alive).  The 
caller  would  be  unable  to  use  methods  that  depend  on  the  file  being  open,  for  example  read.  This 
imprecision  is  analogous  to  state  of  Java  collections  before  generics;  the  return  type  of  the  pop 
method  of  Stack  could  only  guarantee  that  the  returned  object  was  of  type  Object. 

In  practice  [3]  we  have  seen  that  when  using  the  Access  Permissions  methodology  for  types- 
tate  checking,  one  is  forced  either  to  copy  and  re-specify  an  implementation  of  a  collection  several 
times,  once  for  each  context  in  which  it  is  used,  or  settle  for  false-positives.  Collections  are  fre¬ 
quently  used  as  a  means  of  ownership  transfer  between  different  threads  and  different  program 
structures. 

This  paper  presents  a  type  system  that  allows  us  to  give  Stack  a  single  polymorphic  specifi¬ 
cation.  A  stack  of  unique,  open  files  can  share  an  implementation  with  a  stack  of  shared,  open 
sockets  without  losing  precision,  such  as  in  the  specification  of  the  pop  method. 

This  paper  will  proceed  in  the  following  manner:  Section  2  contains  a  brief  recap  of  the  type 
system  of  Bierhoff  and  Aldrich  [2]  upon  which  this  work  directly  builds.  Section  3  describes 
the  type  system  in  technical  detail  and  contains  the  primary  contribution  of  this  work.  As  the 
section  progresses,  we  will  attempt  to  motivate  our  new  features  and  present  a  number  of  useful 
examples.  Since  the  specifications  end  up  being  rather  verbose,  Section  4  shows  how  we  can 
introduce  syntactic  sugar  that  greatly  decreases  the  size  of  specifications  written  by  programmers. 
Section  5  describes  our  implementation  before  a  discussion  of  related  work  and  a  conclusion. 


2  Background:  Access  Permissions 

Because  our  system  is  an  extension  of  the  type  system  of  Bierhoff  and  Aldrich  [2],  some  under¬ 
standing  of  that  system  is  necessary  to  understand  our  work.  In  this  section,  we  will  briefly  recap 
a  few  of  the  more  novel  aspects  of  this  existing  work. 

Bierhoff  and  Aldrich  [2]  presented  a  type  system  for  statically  ensuring  that  object  protocols 
would  not  be  violated  at  run-time.  This  system  had  a  variety  of  novel  features.  For  one,  it  allowed 
a  larger  variety  of  aliasing  patterns  than  previous  approaches.  It  is  important  for  static  typestate 
checkers  to  track  aliasing  in  some  manner  because  of  the  possibility  of  other  references  modifying 
the  state  of  an  object  that  is  being  tracked.  While  existing  typestate  checkers  required  linearity  for 
any  object  with  states  [7],  Bierhoff  and  Aldrich  [2]  introduced  five  permission  kinds,  described 
in  Figure  1,  which  record  statically  which  references  in  a  program  could  be  used  to  modify,  and 
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getlnt( . . .) 


nextO/netunn  true  next( )/return  false 


Figure  3:  A  graphical  depiction  of  the  protocol  defined  by  the  ResultSet  class  in  the  Java  JDBC 
library  [3]. 


whether  or  not  other  references  might  alias  the  same  object.  The  result  was  greater  flexibility  of 
aliasing  for  tracked  objects. 

This  approach  also  associated  each  access  permission  with  a  series  of  fractions.  Fractions  [6], 
as  used  in  verification,  allow  weaker  aliasing  permissions  to  be  recombined  in  order  to  form 
stronger  permissions.  The  numerical  value  of  the  fractions  indicate  to  the  analysis  at  what  point  it 
is  guaranteed  that  all  aliases  have  been  eliminated.  With  fractions,  a  unique  permission,  for  ex¬ 
ample,  can  be  temporarily  split  into  three  share  permissions,  distributed  to  references  in  different 
parts  of  the  program,  and  then  be  recombined  into  a  unique  permission. 

Finally,  this  approach  allows  classes  to  define  state  hierarchies,  which  can  exponentially  de¬ 
crease  the  number  of  cases  that  must  be  considered  when  writing  specifications.  If  a  class  defines  a 
number  of  states,  state  refinement  allows  that  same  class,  or  its  subclasses,  to  introduce  new  states 
inside  existing  states.  Consider  the  protocol  defined  by  the  ResultSet  class  in  Java’s  JDBC  li¬ 
brary,  modeled  as  a  UML  State  Diagram  in  Figure  3.  At  the  top  level  of  the  state  hierarchy  defined 
by  this  class,  there  is  a  simple  Open/Closed  protocol.  When  a  ResultSet  is  closed  by  calling 
the  close  method,  any  underlying  database  resources  will  be  released.  But  within  the  open  state, 
we  can  see  that  there  is  a  much  more  interesting  protocol.  Each  time  the  next  method  is  called, 
the  database  result  will  advance  to  the  next  row  in  the  collection  of  results.  If  this  method  returns 
false,  this  indicates  that  there  are  no  more  rows  in  the  result.  Only  if  this  method  returns  true, 
do  we  say  that  the  result  is  in  the  valid  state,  at  which  point  the  values  for  each  column  can  be 
queried.  Finally,  the  wasNull  method,  which  checks  to  see  if  the  last  column  queried  was  actually 
the  database  value  “NULL,”  can  only  be  called  after  some  column  in  the  current  row  has  been 
queried.  State  hierarchies  like  this  one  allow  simpler  specifications,  since  some  methods  may  be 
ambivalent  as  to  where  exactly  in  the  hierarchy  an  object  lies.  Lor  example,  the  close  method 
requires  only  that  the  receiver  be  somewhere  in  the  open  state,  and  does  not  care  if  the  result  is 
valid,  unread,  etc. 

As  part  of  the  state  hierarchy  methodology,  a  permission  can  provide  a  state  guarantee.  A 
permission  with  a  guarantee  promises  that  reference  cannot  be  used  to  leave  the  guaranteed  state. 
Moreover,  because  of  the  means  by  which  guarantees  are  created,  a  permission  with  a  guarantee 
also  knows  that  no  other  reference  can  be  used  to  leave  that  guaranteed  state.  This  mechanism 
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exists  to  make  certain  weak  permissions,  for  example  share  which  indicates  that  any  number  of 
modifying  aliases  may  exist  to  the  same  object,  much  more  useful.  For  instance,  we  might  create  a 
permission  for  a  ResultSet  that  guarantees  the  open  state.  This  would  ensure  that  no  matter  how 
many  aliases  were  created,  none  of  them  would  ever  be  able  to  close  the  object.  And  thanks  to 
fractions,  by  gathering  back  together  each  permission  created  with  that  guarantee,  we  can  remove 
the  guarantee  later  on,  and  close  the  result  set. 

There  is  also  a  notion  of  state  dimensions.  Dimensions  refine  states  as  well,  but  unlike  states 
which  are  mutually  exclusive  (an  object  can  only  be  in  one  state  at  a  time  on  a  given  level  of 
the  hierarchy)  dimensions  are  concurrent  (an  object  must  be  in  one  state  in  every  dimension  on  a 
given  level  of  the  hierarchy).  This  allows  us  to  model  classes  that  define  multiple,  orthogonal  state 
machines.  Dimensions  in  practice  are  quite  a  bit  like  Data  Groups  [12].  We  will  use  the  general 
term  “node”  to  refer  to  both  states  and  dimensions. 

In  order  to  keep  track  of  all  of  these  elements,  Access  Permissions,  the  static  predicates  associ¬ 
ated  with  each  reference  at  every  program  location,  have  the  following  form  (see  Figure  5  for  the 
full  syntax): 

access  (r,n,g,k,A) 

r  is  the  reference  with  which  the  permission  is  statically  associated,  n  is  the  currently  guaranteed 
state.  If  no  state  is  guaranteed,  this  will  be  “alive,”  the  root  of  the  hierarchy  for  every  type,  g  is  the 
fraction  function.  It  maps  each  state  in  the  state  hierarchy  between  the  guaranteed  node  and  “alive” 
to  a  fraction  between  zero  and  one.  By  keeping  track  of  these  fractions,  we  can  tell  when  it  is  safe 
to  remove  a  previously-established  guarantee,  because  other  aliases  no  longer  depend  on  it.  k  is  the 
below  fraction.  It  exists  so  the  analysis  can  track  whether  or  not  the  associated  reference  has  the 
right  to  modify  the  current  state  of  the  object  (if  the  value  is  greater  than  zero)  and  if  this  reference 
is  the  only  reference  that  has  the  ability  to  do  so  (if  the  value  is  one).  Finally,  A  is  the  current  state 
of  the  object  pointed  to  by  the  reference.  In  the  next  section  we  will  show  how  our  polymorphic 
extension  allows  programmers  to  abstract  over  each  element  of  the  access  permission. 

Access  Permissions  are  tracked  linearly  as  they  flow  throw  the  body  of  a  method,  and  they 
are  updated  as  each  step  of  the  method  dictates.  By  tracking  them  linearly,  we  ensure  that  no 
permission  is  unsoundly  duplicated.  A  series  of  splitting  and  merging  rules  allows  permissions  of 
one  kind  to  be  created  from  or  in  place  of  other  permission  kinds  where  it  is  sound  to  do  so. 

Four  of  the  five  permission  kinds  defined  in  Figure  1  are  actually  represented  in  our  calculus  as 
access  permissions  of  this  form.  These  definitions  are  as  follows: 

unique  =  access(r,  n,  {g,  n  i->  1},  1,  A) 
full  =  access(r,  n,  g ,  1,  A) 
share  =  access(r,  n,  g ,  k,A)  (0  <  k  <  1) 
pure  =  access(r,  n,  g ,  0,  A) 

Both  unique  and  full  permissions  have  a  below  fraction  of  one,  indicating  that  we  can  modify  A, 
the  current  state  of  the  object,  through  r,  and  that  no  other  references  have  that  right.  The  unique 
permission  also  has  a  fraction  of  one  to  the  guaranteed  node  n,  ensuring  that  no  other  references 
rely  on  the  object  being  in  state  n,  and  giving  it  the  freedom  to  change  the  guaranteed  state.  A 
share  permission  has  a  below  fraction  between  one  and  zero,  indicating  that  it  can  be  used  to 
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modify  the  current  state  of  the  object,  but  that  other  references  may  also  have  that  right.  Finally 
the  pure  permission,  whose  below  fraction  is  zero,  does  not  have  the  right  to  modify  A. 

For  simplicity,  we  will  leave  the  immutable  permission  kind  out  of  our  formal  treatment,  but  it 
can  be  represented  by  adding  an  additional  flag  to  distinguish  share  and  immutable  permissions. 


3  Polymorphic  Access  Permissions 

This  section  describes  our  type  system  in  technical  detail.  The  basic  idea  is  to  take  each  ele¬ 
ment  of  the  Access  Permission  and  allow  the  programmer  to  abstract  over  it  at  the  method  and 
class  levels.  Bounds  on  these  abstracted  variables,  enforced  at  instantiation-time,  ensure  that  the 
well-formedness  rules  of  the  Access  Permissions  are  respected.  Additionally,  and  perhaps  most 
interestingly,  the  system  allows  programmers  to  abstract  over  the  classifiers  of  fractions  and  frac¬ 
tion  functions,  not  just  the  fractions  themselves.  This  is  useful  because  it  allows  programmers  to 
instantiate  a  collection  with  a  permission  kind  while  remaining  ambivalent  about  the  exact  fraction 
values. 

Figure  4  gives  the  basic  syntax  for  a  core,  object-oriented  language  with  mutable  state,  inspired 
by  Featherweight  Java  [10].  While  this  syntax  is  essentially  the  same  as  previous  work  [2],  there 
are  a  few  points  to  keep  in  mind.  Each  class  can  declare  a  number  of  new  states  and  dimensions, 
R.  Dimensions,  d,  refine  existing  states  by  introducing  a  number  of  new,  mutually  exclusive  sub¬ 
states.  As  previously  mentioned,  an  object  must  always  be  in  one  state  in  each  dimension  that  it 
defines.  Any  state  or  dimension  can  be  associated  with  a  predicate,  called  a  state  invariant,  N, 
that  must  hold  whenever  the  object  is  in  that  node.  Our  language  has  a  limited  form  of  constructor 
/  which  can  only  specify  an  object’s  initial  state  (or  conjunction  of  states  for  objects  of  multiple 
dimension)  and  the  predicate  required  to  establish  that  initial  state.  Field  declarations  F  declare 
that  a  field  is  “mapped”  into  a  node,  and  that  field  can  only  be  modified  when  the  object  is  in 
that  node.  This  helps  ensure  that  state  guarantees  actually  guarantee  an  object’s  concrete  state. 
Every  method  has  a  specification,  MS,  which  consists  of  a  pre-  and  post-condition,  showing  which 
permissions  it  requires  for  the  receiver  and  parameters,  and  which  permissions  it  returns  upon 
completion.  State  invariants  and  method  specifications  are  written  using  predicates  P  (Figure  5), 
the  standard  forms  of  linear  logic  [9].  Access  Permissions  p,  mention  fractions  k  and  fraction 
functions  g.  A  fraction  is  a  literal  0  or  1,  or  a  fraction  divided  by  two.  A  fraction  function  is  the 
mapping  of  a  node  to  a  fraction,  a  fraction  function  divided  by  two  or  the  concatenation  of  two 
fraction  functions.  Programs  must  be  written  in  a  let-normal  form.  Most  terms  and  expressions  are 
straightforward  with  the  exception  of  pack  and  unpack.  These  two  expressions  are  used  together 
and  delineate  portions  of  code  where  an  object  is  temporarily  not  in  any  state.  They  help  us  check 
that  a  method  actually  changes  the  state  of  the  receiver  object  when  its  specification  says  it  does. 

3.0.1  The  Syntax  of  Permissions  and  Abstraction 

The  most  interesting  new  addition  to  the  syntax  is  the  ability  to  introduce  type  variables  at  the 
class  level,  and  permission  variables  at  the  class  and  method  level.  As  seen  in  Figure  4,  a  class 
can  introduce  any  number  of  type  variables,  f3.  Type  variables  allow  classes  to  be  generic  over 
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programs  PR 
class  decl.  CL 

field  decl.  F 

state  decl.  R 

initial  state  I 

state  inv.  N 

meth.  decl.  M 

meth.  spec.  M S 

terms  t 

expressions  e 


references  r 

types  T 

nodes  n 


(CL,  e ) 

class  C(/3)[a  :  n]  extends  C'(T)[a ]  {  F  R  I  N  M  } 
f  :  T  in  n 

d  —  s  refines  s0 
initially  (P,s i  <g)  . . .  <g)  sn) 
n  —  P 

T  m[aTK](TFr)  :  MS  =  e 
P  -o  E 

x  |  true  |  false 

t,\  and  t,2  |  t\  or  f2  |  not  t 
t  |  /  | ^assign  /  :=  t 

new  C(T) [a] (t)  \  to-m\a](t)  |  super. m[a](t) 
if(t,ei,e2)  |  let  x  —  e\  in  e2 

unpack(n,  k,  A)  in  e  |  pack  n  to  A  in  e 

x  |  / 

bool  |  [3  |  C(T)[d ] 
a  I  s  I  d 


classes  C  fields  f  variables  x 

methods  m  states  s  dimensions  d  type  variables  (3 


Figure  4:  Syntax  I:  Programs,  Classes,  Terms  and  Expressions 

other  types  and  should  be  recognizable  to  those  familiar  with  other  polymorphic  object  calculi,  for 
example  FGJ  [  10] 1 .  Permission  variables  are  more  interesting. 

A  permission  variable,  a,  can  be  introduced  for  the  scope  of  an  entire  class,  or  just  a  method. 
Each  permission  variable  must  be  declared  with  an  associated  quantification  classifier ,  n,  whose 
syntax  is  described  in  Figure  5.  This  classifier  determines  what  a  variable  can  be  used  for  within  its 
scope,  and  what  sort  of  permission  element  can  be  instantiated  for  it.  Those  instantiating  elements, 
a,  are  applied  at  the  site  of  the  method  call  and  object  instantiation  expressions  and  become  part  of 
the  class  types,  C(T) [a]. 

But  what  is  the  nature  of  the  quantification  classifiers?  Recall  that  an  Access  Permission,  p  in 
Figure  5,  has  the  following  form: 

access (r,n,  g,k,  A) 

Our  system  allows  each  element,  with  the  exception  of  the  reference  with  which  the  permission  is 
associated,  to  be  abstracted.  Therefore,  depending  on  the  classifier  that  is  used,  a  newly  introduced 
variable  can  stand  for  n,  g,  k,  or  A.  The  forms  of  the  quantification  classifier,  n,  therefore  are 

'We  have  included  traditional  parametric  polymorphism  in  order  to  make  our  examples  more  compelling.  While 
we  have  left  out  more  interesting  features  like  F-bounded  polymorphism,  we  believe  that  these  features  are  orthogonal 
and  can  be  added  without  any  great  difficulty. 
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quant,  class,  k  ::=  a  |  Asmp(n,  k,  T)  \  u j  |  f2(cc,a;) 

|  £  |  H(0  |  Noder 

fract.  funct.  type  oj  ::=  FF (n,n,T)  |  UFF (n,n,T) 

fract.  type  £  ::=  Fract  |  Decimal  |  1  |  0  |  LessThanl  |  GreaterThanO 

inst.  elems.  a  ::=  ot\A\uj\£>\k\g 
permissions  p  ::=  access  (r,n,  g,k,  A) 
facts  q  ::=  t  =  true  |  t  =  false 

assumptions  A  ::=  a  \  n  \  Ai  ®  A2  |  Ai  ©  A2 

fraction fct.  g  ::=  a  \  nvp-k  \  gj 2  |  gx , g2 

fractions  k  ::=  a  \  1  |  0  |  kj 2 

predicates  P  ::=  p  \  q  \  P\  ®  P2  \  1  |  Pi  &  P2  \  T  |  P\  ©  P2  \  0 

3  ar.n.P 

expr.  types  E  ::=  3 x  :  T.P 
fract.  terms  h  ::=  g  \  k 

valid  context  Y  ::=  •  |  Y,CL  \  Y,x:T  \  Y,/3  \  Y,a:n  \  Y,q 

linear  context  A  ::=  •  |  A ,P 

packedness  v  ::=  •  \  unpacked (n,g,k,A) 

quantification  variables  a 

Figure  5:  Syntax  II:  Permissions,  Abstraction  and  Checking 

Node,  a  node  type,  u,  a  fraction  function  type,  £,  a  fraction  type,  and  Asmp,  an  assumption  type, 
respectively.  Variables  of  type  u  can  only  be  instantiated  with  fraction  functions,  and  variables  of 
type  £  can  only  be  instantiated  with  fractions,  etc.  The  fact  that  these  newly  introduced  quantifi¬ 
cation  variables  can  be  used  as  elements  of  the  Access  Permission  is  reflected  in  the  syntax,  as  a 
appears  as  a  valid  form  of  the  syntactic  categories  n,  g,  k,  and  A. 

The  three  other  forms  of  quantification  classifiers,  a,  0,  and  5,  are  used  to  further  abstract  over 
the  classifiers  themselves,  “one  level  up.”  They  will  be  covered  in  a  subsequent  section.  Thus  far 
we  have  also  neglected  to  discuss  the  various  adornments  of  the  quantification  classifiers,  such  as 
n,  k  and  T  in  the  classifier  Asmp(n,  n.  T).  These  adornments  form  an  overall  part  of  the  bound 
on  the  quantification  variable,  and  as  we  will  show  in  the  next  section,  are  necessary  in  order  to 
ensure  that  Access  Permissions  that  mention  quantification  variables  remain  well-formed. 

3.0.2  The  Static  Semantics  of  Permissions  and  Abstraction 

Every  time  a  programmer  writes  down  a  specification,  which  may  consist  of  a  number  of  Access 
Permissions,  the  static  semantics  of  our  language  ensure  that  those  permissions  are  well-formed. 
The  system’s  well-formedness  rules  prevent  certain  programmer  mistakes,  such  as  the  use  of  ab¬ 
stract  states  that  have  not  been  defined.  These  well-formedness  rules  motivate  many  of  the  features 
of  our  quantification  classifiers.  Let  us  consider  the  permission  well-formedness  rule  presented  by 
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Bierhoff  [1]: 

Old  WF-Perm 

r  h  r:C  C  \~  A  -<  n 

T  h  g  :  n  (->•  Fract  n  =  {all  nodes  between  alive  and  n  inclusive  for  C }  Y  h  k  :  Fract 

r  h  access(r,  n,  g,  k,  A)  wf 

This  is  to  say  that,  in  some  type-checking  context,  a  permission  is  well-formed  if  the  reference 
has  class  type  C,  the  assumption  A  only  mentions  nodes  below  or  equal  to  the  guaranteed  node 
n  in  the  state  hierarchy  of  C,  the  fraction  function  g  maps  a  sequence  of  nodes  n  to  fractions, 
those  nodes  include  all  of  nodes  of  C  between  alive  and  n,  and  A;  is  a  fraction.  Since  at  the  time 
that  quantification  variables  are  introduced  it  is  not  known  exactly  which  permission  elements  will 
be  instantiated  for  them,  it  is  the  job  of  the  quantification  classifiers  to  ensure  that  a  well-formed 
permission  mentioning  quantification  variables  will  remain  well-formed  when  those  variables  are 
instantiated. 

Suppose  we  wanted  to  create  a  simple  class  that  holds  a  field  of  parametrized  type  and  with 
parametrized  permission.  Here  is  how  we  might  declare  such  a  class: 

class  0neField</3>[an  :  Node^m,  :  FF(a„,  alive,  /?),  ak  :  Fract, au  :  Asmp(an,  Fract,  /?)] 
extends  Object  <>[]  { 
f  :  f3  in  alive 

alive  =  access{£,  an,ag,ak,ctA)  //  state  invariant 


} 

Let  us  examine  each  classifier  in  turn.  an,  an  abstraction  of  a  guaranteed  node,  is  declared 
to  have  the  classifier  Node/?.  This  classifier  says  that  an  must  be  instantiated  with  a  node,  and 
that  node  must  be  a  node  in  the  state  hierarchy  of  type  /3.  While  we  do  not,  as  of  yet,  know  what 
this  type  will  be,  an  will  be  instantiated  after  the  type  variable  (3,  at  which  point  it  will  be  clear 
whether  or  not  the  instantiated  node  is  a  node  of  the  instantiated  type.  Next,  ag  is  classified  as 
FF(an,  alive,  /3).  This  tells  us  that  ag  can  only  be  instantiated  with  fraction  functions,  and  those 
fraction  functions  must  contain  a  fraction  for  every  node  in  the  state  hierarchy  of  (3  between  an 
and  alive  inclusive.  Note  how  the  bound  of  one  quantification  variable  is  dependent  on  other 
quantification  variables.  The  classifier  of  ak,  Fract  says  that  it  can  only  be  instantiated  with  a 
fraction.  Finally,  the  classifier  for  a  a,  Asmp(an,  Fract.  3)  records  that  the  variable  can  only 
be  instantiated  with  assumptions  (i.e.,  the  syntactic  form  A).  Furthermore,  it  stipulates  that  the 
instantiating  assumption  must  be  below  an  in  the  state  hierarchy  of  type  /3  and,  if  the  classifier 
Fract  can  classify  fractions  below  one  (which  in  this  case  is  trivially  true!)  the  instantiating  element 
for  a  a  must  be  equal  to  an. 

This  last  restriction  deserves  some  mention.  If  a  collection  holds  elements  of  share  or  pure 
permission  kind,  it  must  account  for  the  fact  that  the  state  of  these  elements  can  be  changed  under 
the  guaranteed  node  at  any  time.  The  assumption  is  therefore  tied  to  the  guarantee  and  can  only  be 
below  the  guarantee  if  the  eventual  instantiating  fraction  for  ak  is  one.  (At  the  moment,  a  a  must 
trivially  always  be  equal  to  a^,  but  after  “classifier  classifiers”  are  introduced,  this  will  no  longer 
be  the  case.) 
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Var 
a\K  G  T 


SUBSM 

r  b  a  :  k  T  h  k  C  k' 

r  b  a  :  k' 


T  b  u  :  Q(uj,  co) 


T  b  a  :  k 

r  b  £  :  2(0  r  b  0  :  0 

Same  Fract 

r  b  k  :  k  k  □  LessThanl 

T  b  k/ 2  :  k 

r  b  g  :  UFF(ni,n2,T) 
r  b  g/2  :  FF(ni,n2,T) 

r  b  k  :  1  r  b  n  :  NodeT 
rbnGfc:  UFF(n,  n,  T) 


r  b  k  :  GreaterThanO 

rbl:l  - 

r  b  k/ 2  :  Decimal 

FF-DIV2 

rbfc:  Fract  rbg:  FF(ni,  n2,  T) 

T  b /c/2  :  Fract  T  b  g/2  :  FF(ni,  n2,  T) 

r  b  k  :  Decimal  r  b  n  :  NodeT 

r  b  n  G  b  FF(n,  n,  T) 

T  b  g\  :  UFF(n,  rb,  T)  T  b  gf2  :  FF(n/,  n;',  T) 
F  b  ^i,^2  :  UFF(n,  n",  T) 


rbjF  FF(n,  n',  T)  Tb  g2  :  FF  (n',  n",  T) 
F  b  gug*:  FF (n,n",T) 


Figure  6:  Classification  of  fractions  and  fraction  functions. 


The  responsibility  of  ensuring  that  an  instantiating  permission  element,  a,  satisfies  the  bound 
imposed  on  it  by  a  quantification  classifier,  k  falls  on  our  type  system.  This  is  accomplished  with 
the  judgment,  T  b  a  :  n,  which  says  that  under  a  valid  typing  context  T,  the  instantiating  element 
a  can  be  classified  with  k.  The  rules  for  this  judgment  are  shown  in  Figures  6  and  7. 

Some  discussion  of  these  rules  is  in  order.  The  Var  rule  says  that  any  quantification  variable 
has  the  classifier  that  it  was  declared  to  have.  The  SUBSM  rule  says  that  any  element  a  with 
classifier  k  can  be  treated  as  being  of  classification  k'  if  k  is  a  subclassifier  of  k1.  The  next  two 
rules  say  that  classifiers  themselves  have  classifiers,  which  we  will  motivate  later.  Every  fraction 
form  has  a  classifier,  including  the  literals  1  and  0,  whose  classifiers  are  the  literals  themselves. 
Fraction  functions  can  be  classified  as  either  FF,  the  classification  of  all  fraction  functions,  or  as 
UFF,  the  classification  of  unique  fraction  functions,  that  is  fraction  functions  whose  lowest  node 
maps  to  the  fraction  1.  Rule  Alive  says  that  alive  is  a  node  for  any  type.  Rule  Ground  says  that 
a  node  is  defined  in  class  C  at  any  instantiation  if  it  is  declared  in  class  C.  Finally,  any  node  n 
can  be  an  assumption  below  or  equal  to  node  n  for  any  fraction  classifier,  but  two  assumptions  can 
only  be  joined  to  form  an  assumption  if  both  assumptions  are  below  some  common  node  n,  and 
the  classifier  bound  in  Asm p  is  1. 

Now  that  we  have  seen  the  variety  of  classifiers  available  in  our  type  system  and  how  each  per¬ 
mission  element  is  classified,  let  us  present  the  new  well-formedness  rule  for  permissions,  which 
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Ground 

T  b  n  from  C  r  I -  n:  Noder 

r  I -  n:  Node^^fc]  r  I -  n:  Asmp(n,  k,  T) 

T  h  A2  :  Asmp (n",  1  ,T)  F  h  n  <  n  V  h  n"  <  n 
F  h  Ai  <8)  A2  :  Asmp (n,  1,  T) 

F  h  Ax  :  Asmp(n'.  1 ,  T)  r  h  A2  :  Asmp(n",  1,  T)  T  h  n  <n  F  h  n"  <  n 

F  h  A1  ©  A2  :  Asmp(n,  1,  T) 


Alive 

r  I-  alive  :  Noder 

r  h  Ai  :  Asmp(n'.l,T) 


Figure  7:  Classification  of  nodes  and  assumptions. 

updates  Old  WF-Perm  presented  earlier  in  this  section: 

r  h  r  :T  F  h  n  :  Noder 

r  h  g  :  FF  (n,  alive.  T)  r  h  k  □  Fract  T  h  A  :  Asmpfn,  /c,  T) 

WF -Perm - 

T  F  access(r,  n,  g,  k,  A)  wf 

Thanks  to  our  changes,  the  classifiers  of  each  element  of  the  permission  succinctly  express 
the  restrictions  on  each  element.  Note  that  the  classifier  of  k,  k  is  the  same  n  mentioned  in  /l’s 
classifier.  This  restriction,  coupled  with  the  assumption  classification  rules  in  Figure  7,  ensure  that 
n  —  A  for  any  polymorphic  permission  with  a  fraction  k  less  than  one.  Using  WF-Perm,  our 
type  system  would  find  that  the  state  invariant  for  the  alive  state  in  the  OneField  class  is  indeed 
well-formed: 

p,f:p,an:  Node^,  ag :  FF(an,  alive,  P),  ak  :  Fract,  aA  ■■  Asmp(an,  Fract,  p) 

I-  access  (/,  an,  ag,  ak,  a  A )  wf 

The  quantification  classifiers  also  form  a  number  of  interesting  subclassification  relationships. 
Subclassification  allows  programmers  to  write  specifications  that  are  quite  expressive,  in  a  way 
that  is  analogous  to  Java’s  F-bounded  polymorphism.  Subclassification  is  established  with  the 
judgment  F  h  k  jZ  k.  The  rules  for  this  judgment  are  presented  in  Figure  8. 

The  main  points  of  interest  are  the  relationships  between  fraction  classifiers,  and  the  relation¬ 
ships  between  fraction  function  classifiers.  Fraction  classifiers  form  a  hierarchy  from  Fract,  the 
classifier  of  every  fraction,  to  0,  1,  and  Decimal,  the  classifiers  for  0,  1,  and  fractions  between  0 
and  1,  respectively.  LessThanl  and  GreaterThanO  have  the  obvious  locations  in  this  hierarchy. 
Fraction  functions  can  be  classified  by  FF,  or  its  subclassifier  UFF.  Fraction  functions  classi¬ 
fied  by  UFF  have  their  lowest  node  mapped  to  1,  and  are  the  fraction  functions  used  for  unique 
permissions. 

3.0.3  Abstracting  Over  Quantification  Classifiers 

While  the  ability  to  abstract  over  fractions  and  fraction  functions  is  useful,  it  is  not  quite  as  flexible 
as  we  would  like.  Consider  the  following  scenario:  We  would  like  to  take  our  stack,  presented 
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Reflexive 

r  b  k  c  k 


Transitive 

r  h  k  c  k' 


rhfi'c  K" 


T  b  1  u  GreaterThanO 


rhftCK" 

r  b  Decimal  u  GreaterThanO  T  I-  GreaterThanO  □  Fract 


ThOC  LessThanl 


T  b  Decimal  u  LessThanl  T  b  LessThanl  u  Fract 


T  b  UFF(ni,n2,T)  jZ  FF(ni,n2,T) 


r b uj[  c ui  rbw2c^ 
T  b  L2(o;i,  cc2)  jZ  fi(u4,  uj'2) 

FF  Lower-Bound 
r  b  a  : 

T  b  w  L  a 


T  b  n  <  n'  in  T  T  b  k  |Z  /b 
T  b  Asmp(n,  a,  T)  jZ  Asmp(n' ,  k',  T) 

FF  Upper-Bound 

rb£E£'  rba:0(_,u) 

TbS(OES(0  TbaCu 

Fract  Upper-Bound 

rba:  5(Q 

TbaC( 


Figure  8:  Subclassification  rules 


back  in  Section  1,  and  specify  it  is  generic  over  the  permission  kind  of  the  elements  it  holds,  but 
where  every  each  element  must  be  of  the  same  kind.  We  will  only  concentrate  on  the  class  quantifi¬ 
cation  variables  and  the  push  method,  since  this  will  be  enough  to  motivate  higher  quantification. 
Consider  the  following  specification  of  Stack: 

class  Stack<b>[an  :  Node^Og  :  FF(an, alive, /?), ak  :  Fract,  :  Asmp(a„,  Fract, /3)] 
extends  Object  <>[]  {  ... 

boolean  push(T  i)  :  unique(this)  <g>  accessfi,  an,  ag,  ak,  aA)  unique(this) 

.  .  .  } 

Now,  suppose  that  at  a  particular  instantiation  site,  we  would  like  to  use  this  stack,  and  we 
would  like  it  instantiated  as  a  stack  of  shared  permissions  to  files  that  are  guaranteed  to  be  open. 
What  instantiations  should  we  use?  Unfortunately,  we  are  required  to  choose  definite  values  for  the 
fraction  ak ,  and  the  fraction  function,  ag.  Let  us  assume  that  we  instantiate  the  stack  as  follows; 
Stack(File)  [Open,  {alive  .Open  i-A  |},  |,Open].  This  means  that  in  an  environment 
where  the  permission  accessf/iq,  Open,  {alive  ,  Open  -►§}  ,  Open),  a  share  permission, 
is  available  for  r1,  the  call  push(ri)  is  legal.  Unfortunately,  if  we  have  another  share  permission 
with  different  fraction  values,  say  access(r2,  Open,  {alive  ,Open  ~  b.  |,Open),  the 
call  push(r2)  is  not  legal,  because  the  pre-condition  for  the  push  method  when  instantiated  is 
unique(stack)  ®  access(ri,  Open,  {alive  ,  Open  i  y  |},  {,  Open).  This  requires  the  exact 
same  fraction  and  fraction  function  values. 


12 


To  accomplish  our  original  goal  of  instantiating  a  stack  that  can  hold  share  permissions  at  any 
fraction,  we  need  more  power  in  the  specification  language.  We  need  the  ability  to  quantify  over  the 
classifiers  themselves.  Fortunately,  the  quantification  classifiers  D  and  5  let  us  do  exactly  that.  Q  is 
the  classifier  of  all  fraction  function  classifiers.  It  stores  an  upper  bound  and  a  lower  bound  of  the 
classifiers  that  can  legally  be  used  to  instantiate  it.  H  is  the  classifier  of  fraction  classifiers.  It  stores 
an  upper  bound  of  the  classifiers  that  can  legally  be  used  to  instantiate  it.  (Why  no  lower  bound? 
It  was  not  found  to  be  useful  for  any  of  our  examples.  Adding  it  would  be  fairly  straightforward.) 
By  abstracting  over  these  “classifier  classifiers,”  we  can  specify  that  certain  fractions  and  fraction 
functions  must  be  similar  but  not  identical. 

With  f?  and  H  at  our  disposal,  we  can  finally  specify  the  Stack  class  in  the  way  that  we  desire: 

class  Stack</3>[an  :  Node^o^  :  ff(UFF(an, alive, (3),  FF(a„,  alive, /?)), 

:  S(Fract),«A  :  Asmp(an, aj, /?)] 

extends  Object  <>[]  { 

boolean  push(T  i)  : 

unique(this)  ®  {3ag-.au,.3ak:a^ .access(i,  an,  ag,  ak,  «a))  — °  unique(this) 

.  .  .  } 

With  a  stack  instantiated  as,  Stack(File)[Open,  FF(Open,  alive,  File),  Decimal,  Open], 
we  can  call  the  push  method  and  pass  share  permissions  of  any  fractional  value.  This  is  in  part 
thanks  to  the  existential  quantification  that  has  been  added  to  the  push  method’s  specification. 
When  instantiated,  it  can  accept  any  fraction  as  long  as  that  fraction  is  classified  by  Decimal,  and 
any  fraction  function,  provided  it  is  classified  by  FF. 

3.0.4  Quantifying  Over  Symmetric  Permission  Kinds 

Up  until  this  point,  we  have  used  Stack  as  a  running  example.  One  of  the  notable  features  of 
stack  is  that  it  can  hold  permissions  of  any  kind.  This  is  largely  due  to  its  implementation.  A 
programmer  can  push  an  object,  and  the  stack  will  capture  some  permission  associated  with  that 
object.  Later  on,  when  the  pop  method  is  called,  the  entire  permission  to  the  returned  element  is 
forfeited  by  the  stack.  This  means  that  no  matter  what  permission  kind  the  stack  holds,  we  can 
count  on  getting  it  back  later  in  the  execution. 

However,  some  data  structures  do  not  provide  this  feature,  and  yet  could  still  reasonably  support 
multiple  permission  kinds.  The  polymorphic  type  system  we  have  presented  here  allows  us  to 
precisely  specify  the  behavior  of  these  classes.  Consider  the  mutable  linked  list  class  shown  in 
Figure  9.  It,  like  many  of  the  collection  classes  in  the  Java  standard  library,  provides  random 
access  to  its  elements.  If  we  would  like  to  use  this  list  in  a  larger  program  that  we  are  attempting 
to  verify,  we  must  ask  what  kind  of  permission  we  can  get  back  from  the  get  method,  especially 
in  light  of  multiple  calls  to  the  same  element: 

Object  o_l  =  list.get(Q); 

Object  o_2  =  list.get(Q); 

Does  the  second  call  return  the  same  permission?  Does  it  return  no  permission?  Does  it  generate  an 
error?  There  are  multiple  ways  we  might  want  our  list  to  behave.  One  observation  is  that  this  linked 
list  can  hold  elements  of  any  permission  kind  that  can  be  split  indefinitely  to  produce  the  same 
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Figure  9:  A  linked  list  that  provides  random  access  to  its  elements. 

permission.  We  call  such  permissions  “symmetric,”  and  both  the  share  and  pure  permissions  have 
this  property  (along  with  the  immutable  permission,  which  is  not  part  of  our  formal  treatment). 
Using  classifier  bounds,  our  type  system  allows  us  to  specify  LinkedList  in  such  a  way  that  it 
can  be  used  for  share  and  pure  but  not  full  or  unique. 

Here  is  how  we  might  specify  the  LinkedList  class:  First,  we  will  introduce  bounded  quanti¬ 
fiers  at  the  class  level: 

class  LinkedList </3> [a„  :  Node^,^  :  fi(FF(a„,  alive, /3),  FF(a„, alive, /?)), 

:  S(LessThan1 ),  a  a  :  Asmp(an,  a^,  /?)]  { 

} 

Here  note  that  the  fraction  classifier  a ^  is  bounded  so  that  it  can  never  classify  any  fraction  whose 
value  is  1  (which  would  be  necessary  for  a  unique  or  full  permission).  The  fraction  function 
classifier  au  is  bounded  from  below  by  FF,  which  means  that  it  can  never  be  used  to  classify  a 
unique  fraction  function  (i.e.,  the  fraction  function  that  would  be  used  in  a  unique  permission). 

The  effect  of  these  bounds  are  two-fold.  First,  they  prevent  unique  and  full  permissions  from 
ever  being  used  to  instantiate  the  linked  list.  This  generally  means  that  a  unique  or  full  permission 
cannot  be  returned  as  a  result  of  calling  the  get  method,  although  because  of  splitting  these  per¬ 
missions  could  still  be  used  to  satisfy  the  pre-condition  of  the  add  method.  Secondly,  these  bounds 
give  the  analysis  enough  information  to  know  internally  that  fractions  classified  by  a $  and  fraction 
functions  classified  by  au  can  be  split  and  still  result  in  a  fraction  of  the  same  classification.  Rules 
Same  Fract  and  FF-Div2  in  Figure  6  make  this  possible. 

To  better  illustrate  this  idea,  let  us  attempt  to  verify  an  implementation  of  the  get  method  of  the 
Node  class,  beginning  on  line  4  of  Figure  9.  Here  is  a  specification  along  with  an  implementation, 


class  LinkedList<T>  { 

class  Node  {  T  item;  Node  next; 

T  get(int  i,  int  cur)  { 

if(  i  ==  cur  )  return  item; 
else  return  next  ==  null  ?  null  : 
next.get(i,  cur  +  1); 

} 

} 

int  size  =  ®;  Node  first  =  null; 

int  size()  {...}  void  add(T  item)  {...} 

T  get(int  i)  { 

if(  first  ==  null  )  return  null; 
else  return  first . get (i , ®) ; 

} 

} 
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assuming  the  quantified  variables  introduced  in  the  previous  listing  are  in  scope,  and  that  our 
language  allows  us  to  work  with  integers: 

class  Node  { 

alive  =  unique(next)  ®  (3ag:au3ak-a^.access(result,  an,  ag,  ak,  oa)) 

(3  get(int  i,  int  cur)  : 

unique(this)  — o  (3ag:au3ak:a^  ,access(result,  an,  ag,  ak,  a  a))  ®  unique(this)  { 
if(  i  ==  cur, 

unpack  (alive ,  1 ,  alive)  in 
let  r  =  item  in 
pack  alive  to  alive  in  r, 
let  n  =  next  in 

if(  n  ==  null,  null,  n . get (i , cur+1)  ) 

} 


} 

Verifying  the  get  method  requires  proving  the  permission  3ag:au.  3 ak:a^.  access(  r,  an,  ag,  ak,  a  a) 
twice,  once  to  satisfy  the  post-condition,  and  once  to  enable  the  receiver  to  be  packed  to  the  alive 
state.  While  splitting  rules  essentially  always  allow  a  access  permission  to  be  split  in  two,  by  di¬ 
viding  its  fraction  and  fraction  functions  in  half,  it  is  the  bounds  on  the  classification  variables  that 
ensure  the  divided  fraction  and  fraction  function  are  still  classified  by  a $  and  au. 

Rules  Same  Fract  and  FF-DIV2  allow  the  following  verification  condition  to  succeed: 

:  Q(. . .),  ag  :  au,  ct?  :  H(. . .),  ak  :  c^;  access  {re  suit,  an,  ag/2 ,  ak/ 2,  a  a) 
h  {3ag:a0j3ak:a^.8LCCess(result,  an,  ag,  ak,  cka)) 


3.0.5  Typing  Rules 

The  type-checking  rules  for  expressions  in  our  language  are  largely  similar  to  the  ones  presented 
by  Bierhoff  and  Aldrich  [2].  Unfortunately,  due  to  space  constraints,  we  are  unable  to  present  them 
all  here.  Instead,  Figure  10  presents  only  the  rules  that  have  changed  due  to  polymorphism  and 
for  the  remainder  we  refer  the  interested  reader  to  existing  work.  The  main  typing  judgment  is 
T;  A;  v  \~c  e  :  E\  v',  which  means,  in  the  context  of  some  valid  facts  T,  some  linear  facts  A,  some 
packed-ness  state  v,  and  within  the  context  of  class  C,  the  expression  e  has  type  E,  and  will  finish 
in  the  packed-ness  state  v'. 

Our  type  system  allows  abstract  states  of  an  object  to  be  associated  with  predicates  over  the 
fields  of  the  object  which  must  hold  whenever  an  object  is  in  the  abstract  state.  We  refer  to  these 
predicates  as  “state  invariants.”  We  use  a  packing/unpacking  methodology  [8]  in  order  check  that 
state  invariants  do  hold,  even  in  the  face  of  reentrant  objects.  In  this  methodology,  a  programmer 
will  exchange  a  permission  to  the  receiver  in  a  certain  state  for  the  state  invariant  predicate  by 
using  the  unpack2  expression.  Before  the  end  of  a  method  body,  and  before  each  method  call  that 
is  potentially  reentrant,  a  programmer  must  use  the  pack  expression  to  reacquire  permission  to  the 
receiver,  at  which  point  there  is  the  burden  of  proving  the  state  invariant  for  the  state  to  which  it 

2Note  that  in  Plural,  our  implementation  of  this  approach,  pack  and  unpack  operations  are  inferred  [3]. 
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P-New 


T  b  C(T0)[a]  wf 

T  h\n\t(C(%)[a])  =  (JTT,aTK,P,A)  T  b  TTT  T  b  aTn  T-,Ah[t/J]P 
T;A;vl-c  new  C(To) [a] (t)  :  3x:C(To)  .access  (x,  alive,  {alive  ha  1},1,A);v 

P-Call  _ 

r  I-  to  ■■  C{T0) [do]  r  b  sargsjyn,  C(T0)  [djj])  =  (oT ~R) 

T  b  a  :  k  T  b  mtype(m[a],  C(T0)[oo])  =  (x  :  T,  P  — °  E) 
r  b  t  :  T  T;  A  b  [t0/this][t0/thiSfr][£/d]P 

r;A;«bc  t0.m[a](t)  :  [f0/this][t/x]P;  • 

P-SUPER  __ 

r_b  this  :  C(Tt)[ai\ 

T  b  stype(C(Ti) [ai])  =  C'(TS ) [al]  r  b  sargs(m, C'(TS) [al])  =  (oTk) 

T  b  cPTK  T  b  mtype(m[a],  C'(Ts)[a^})  =  (x  :  T,  P  E) 

T  b  t  \T  T;  A  b  [super/thiSfr][t/x]P 

T;A;«bc  super. m[a](t)  :  [super/thiSfr][t/r]P;  • 

Figure  10:  Expression  typing  rules  modified  due  to  polymorphism 


is  packed.  The  context  v  tracks  whether  or  not  the  current  receiver  is  packed  or  unpacked  (our 
language  only  allows  access  to  fields  of  the  current  method  receiver). 

Several  typing  rules  defer  to  a  linear  logic  proof  judgment,  T;  A  b  P  from  [2].  We  use  Linear 
Logic  [9]  to  ensure  that  Access  Permissions,  which  are  descriptions  of  how  objects  are  aliased,  are 
not  duplicated  in  an  unsound  manner.  The  judgment  says  that  in  the  context  of  some  valid  facts  T 
and  some  linear  facts  A,  the  predicate  P  is  true. 

Rule  P-New  checks  an  instantiation  expression.  After  checking  that  the  instantiated  type  is 
well-formed,  the  in  it  function  takes  an  instantiated  class  type  and  returns  the  types  of  its  fields, 
the  classifications  of  the  polymorphic  variables,  the  initial  object  state  A  and  the  state  invariants 
for  that  state  P.  Both  the  types  of  the  fields  and  the  initial  state  invariant  are  returned  in  terms  of 
the  instantiating  types  and  permission  elements,  as  the  definition  of  the  init  function  in  Ligure  11 
explains.  The  rule  then  checks  that  the  instantiating  elements  a  are  actually  classified  by  Ti  and 
then  uses  the  current  linear  context  to  prove  the  required  permissions  P,  but  for  the  arguments  that 
are  passed  to  the  constructor,  rather  than  the  fields. 

The  rule  P-Call  checks  a  method  call  site.  The  receiver  is  checked  to  ensure  that  it  has  some 
kind  of  class  type.  The  sargs  function,  defined  in  Ligure  11,  looks  up  the  classifiers  of  the  static 
function  parameters,  and  then  the  permission  arguments,  a,  are  checked  to  ensure  they  have  the 
same  classifiers.  Additionally,  the  method  arguments  are  checked  to  ensure  that  they  have  the  same 
types  as  the  method  parameters.  Note  that  the  mtype  function  (Ligure  11)  takes  into  account  the 
static  arguments  of  f0’s  type,  C'(To)  [do]-  Linally,  the  linear  context  is  used  to  prove  the  method 
pre-condition,  after  all  of  the  appropriate  substitutions  are  made.  The  rule  for  type-checking  calls 
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class  C((3)[a  :  n\  extends  C'(T')[a'\{. . .  f  :  T  inn  initially(P, si  ® ®  sn) . . .}  G  T 

T  h  init(C"(T7)[a7])  =  (/"  :  T",  cPTk7,  P1,  A') 

T;  (P.  access(super,  alive,  {alive  ha  l},  A'))  h  invc(alive,  A)  ®  T 

r  h  init(C(T)[a])  =  ( [T f]3] [a/ a] {JTT, 7"7T") ,  [a/a\(P  ®  P'),  A) 

r  h  init(Object()[])  =  (•,  •,  1, alive) 


class  C(/3)[a  :  k]  extends  C'(TS) [as] {. . .  M  . . .} 

T  m[ am  :  Km\(T  x)  \  P  E  =  e  E  M  n 'm —  [a /a] Tsy 


T  h  sargs(m,  C(T) [a])  =  (am  :  k'v 


class  C((3)[a  :  k]  extends  C' (Ts)[as\{. . .  M  . . .} 

T  m[am  :  Km](T  x)  :  P  E  =  e  E  M 
V  =  %/W_  P'  =  (Mg/gp))  E'  =  [g/gKja/ggg^Mg)) 
r  h  mtype(m[a],  C(Tc)[c^})  =  (aTTT7,  P'  -<>  E') 


class  C(/3)[a  :  n\  extends  C'(Ts)[as]{. . .}  G  T  T'  —  [T//3]TS  a'  =  [a/a]as 


T  h  styp e(C(T)[a})  =  C' (T1) [a'1 


Figure  11:  Various  utility  judgments  used  by  type-checking  and  well-formedness  rules. 

of  superclass  methods,  P-Super,  works  very  much  in  the  same  way.  Our  type  system  uses  a 
“frames”  methodology  [8]  for  ensuring  soundness  in  the  face  of  subclassing,  here  evident  in  the 
appearance  of  the  thisfr  and  super  references. 

Beyond  the  expression  typing  rules,  there  are  also  a  number  of  rules  for  ensuring  that  an  entire 
program  is  well-formed.  These  are  given  in  Figure  12.  Rule  P-Class  checks  that  a  class  is 
well-formed  by  adding  all  of  the  fields,  type  variables  and  quantification  variables  to  the  valid 
context.  Every  declared  quantification  classifier  is  checked  to  ensure  that  it  is  well-formed.  It  then 
checks  that  the  field,  state,  method,  constructor  and  state  invariant  declarations  are  well-formed. 
Rule  P-Method  checks  that  an  method’s  body  correctly  implements  its  specification.  First,  the 
classification  quantifiers  and  argument  types  are  checked  for  well-formedness.  An  augmented 
context  is  used  to  check  that  the  pre-  and  post-conditions  are  well-formed.  The  override  judgment 
checks  that  the  method’s  specification  is  behaviorally  compatible  with  any  methods  it  overrides. 
Finally,  given  the  permissions  specified  in  the  post-condition,  the  method  body  is  type-checked  to 
ensure  that  it  correctly  satisfies  its  post-condition,  and  that  the  receiver  is  packed  on  return  from 
the  method.  Again,  we  regret  that  due  to  space  constraints,  some  judgments  that  are  reused  without 
changes  from  existing  work,  such  as  override,  invc,  linear  logic  proof,  permission  splitting  and 
joining  rules,  and  the  field,  state  and  constructor  well-formedness  judgments,  are  not  presented  in 
this  paper.  Interested  readers  are  referred  to  existing  work  [1]. 
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P-Class 

ftypes(F)  =  JTr  r  =  r,  /?,  JTr,  am  r'hswf  r  h  C'(T )  [a]  wf 
r  h  Fokin  C  r',  this  :  C(J3)\a]  F  M  ok  in  C(j3)\a]  T'hiVok 
r  h  /  Ok  in  C(/3)  [a-]  V  h  R  ok  in  C  M overrides  all  methods  with  this ^  perm  in  C’ 

r  h  class  C(i9)[QTs]  extends  C (T)[d}{F  R  I  N  M}  ok 

P-Method 

r  =  r,  «tk,  aTTT  r  f  ^wf  r'  f  rwf  r'hPwf 
r',  result :  Tr  F  Pr  wf  T!  b  overrid e(m,c((3)[d^\,x  :  T,P  3 result :  Tr.Pr ) 

T7;  P;  •  be  e  :  3 result :  Pr.Pr  <g)  T;  • 

T  b  m[a  :  k\(T  x)  :  P  — °  3 result :  Tr.Pr  =  e  Ok  in  C'(/3)[c^] 

Figure  12:  Well-formedness  rules  for  the  entire  program. 

4  Syntactic  Sugar 

Up  until  this  point  we  have  been  assuming  that  programmer  would  be  writing  out  the  full  specifi¬ 
cations  as  we  have  presented  them  in  our  language.  This  system  is  quite  flexible  and  expressive. 
However,  given  the  syntactic  complexity  of  some  of  the  quantification  bounds,  for  example  [an  : 
Node/?,  :  H(FF(ari, alive,/?),  FF(an, alive, /?)),  :  S(LessThan1 ),  aA  ■  Asmp(an,a?,/?)] 

from  our  linked  list  example,  we  would  really  like  to  simplify  things  a  bit!  In  this  section  we  will 
introduce  syntactic  sugar  that  greatly  simplifies  our  system  of  polymorphic  access  permissions 
while  still  retaining  most  of  the  expressiveness. 

In  order  to  simplify  our  system,  we  will  introduce  polymorphic  variables  that  stand  for  entire 
Access  Permissions,  rather  than  for  each  permission  element.  These  variables,  when  introduced, 
will  be  declared  with  one  of  three  types  of  bounds: 

Exact  This  variable  bound  introduces  a  permission  that  refers  to  a  specific  fractional  quantity. 
Every  time  it  is  used,  the  instantiated  permission  will  be  required  to  be  exactly  the  same. 

Similar  This  variable  bound  introduces  what  is  essentially  a  family  of  permissions  each  of  the 
same  permission  kind.  Every  time  this  permission  variable  is  used,  instantiations  are  required 
to  be  of  the  same  kind,  but  not  necessarily  the  same  fraction. 

Symmetric  This  variable  bound  introduces  a  permission  variable  that  is  identical  to  ‘Similar’ 
in  every  way,  and  additionally  can  be  divided  an  infinite  number  of  times.  Therefore,  it 
can  only  be  instantiated  with  permissions  of  kind  pure  and  share  (and  immutable  in  our 
implementation) . 

Using  these  simplified  bounds,  the  linked  list  class  presented  in  the  previous  section  could  be 
written  in  the  following  manner: 

class  LinkedList</3>[p  :  symmetric//?)]  { 
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r  I-  rii  <  n2  in  T  T  F  T  wf 
T  F  FF(ni,  n2,  T)  wf 


VAR-0 

T  F  a  :  0(c^i,  c^2) 

T  h  a  wf 


Var-H 

r  F  a  :  5(Q 

Tl-awf 


r  F  ni  <  n2  in  T  TFT  wf 
T  h  UFF(ni,  n2, T)  wf 


FF  Type 

rhwjwf  r i- ^2 wf  r f c CU2 
r  h  £l(ui,U2)  wf 


Node  Assumption 

r  h  T  wf  r  I-  n  :  Noder  rhswf  rh/tE  Fractr  F  T  wf 

r  F  Noder  wf  r  F  Asmp(n,  k,  T)  wf 


Fracts 
T  F  £  wf 


Fract  Type 
r  F  H(0  wf 


Figure  13:  Rules  for  checking  the  well-formedness  of  quantification  classifiers. 


class  Node  { 

/3  item;  Node  next; 
alive  =  unique(next)  ®p(item) 

/3  get(int  i,  int  cur ):  unique(this)  unique(this)  <8>  p(result) 

} 

alive  =  unique(first) 

void  add(/3  item)  :  unique(this)  ®p(item)  unique(this) 

/9  get  (int  i)  :  unique(this)  unique(this)  <g>  p(result) 

} 

The  permission  variable  p  stands  for  a  permission  that  can  be  divided  any  number  of  time  but  will 
still  result  in  a  permission  of  the  same  kind.  Specifically,  each  time  p  is  mentioned,  it  may  refer  to 
different  fractions  in  the  below  fraction  and  the  fraction  function.  Note  that  the  bound  of  p  must 
still  declare  the  type  (3  with  which  its  permissions  will  be  associated. 

These  new  permission  variables  are  truly  syntactic  sugar.  They  can  be  defined  in  terms  of  our 
lower  level  quantification  variables.  For  each  of  the  three  types  of  bounds  for  permission  variables, 
there  is  a  different  way  to  translate  its  declaration  and  its  use.  The  table  in  Figure  14  summarizes 
the  transformation  from  syntactic  sugar  to  the  formal  language. 

Of  particular  note  is  the  translation  of  the  use  of  a  similar  or  symmetric  permission  vari¬ 
able.  Each  use  is  translated  into  an  Access  Permission  that  existentially  quantifies  the  fraction 
and  fraction  functions.  The  classifiers  of  these  existentially  quantified  variables  are  the  classifiers 
introduced  when  the  permission  variable  itself  was  declared.  Additionally,  the  symmetric  permis¬ 
sion  variable  is  rewritten  as  a  series  of  quantification  variables  with  a  fraction  classifier  a^,  that  is 
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Declaration  and  Use 

Sugar 

Rewrite 

p :  exact(T) 

a ^  :  S(Fract),an  :  NodeT,ag  :  FF(ctn,  alive,  T),  ak  :  a^, 
aA  :  Asmp (a„,as,T) 

p(r) 

access(r,  an,  ag,  ak,  aA) 

p  :  similar(T) 

an  :  NodeT,  au  :  0(UFF(an,  alive,  T ),  FF(an,  alive, T)), 

:  ^(Fract),^  :  Asmp(an,Q!$,T) 

p(r) 

3ag:aUJ3ak'.a^.8iCCess(r,  an,  ag ,  ak,  aA) 

p  :  symmetric(T) 

an  :  NodeT,  :  0(FF(an,  alive,  T),  FF(an,  alive,  T)), 

:  S(LessThan1),aA  :  Asmp(an,Q:?,T) 

p(r) 

3ag:aa;.3Q;/c:a^.access(r,  an,  ag ,  ak,  aA) 

Figure  14:  The  translation  of  permission  variables,  which  are  syntactic  sugar,  into  the  formal 
language,  at  both  their  declaration  and  use  site. 


bounded  above  by  LessThanl ,  and  a  fraction  function  classifier  «u,  that  is  bounded  below  by  FF. 

Given  such  a  large  difference  in  syntactic  complexity,  readers  may  reasonably  wonder  whether 
or  not  our  formal  system  could  have  been  written  to  include  these  simplified  polymorphic  per¬ 
missions  from  the  start.  Our  motivation  for  presenting  polymorphic  access  permissions  in  the 
manner  is  two-fold.  First,  we  feel  strongly  that  presenting  the  simplified  polymorphic  permissions 
in  terms  of  a  formal  system  where  each  element  of  the  Access  Permission  can  be  quantified  helps 
in  understanding  the  semantics  of  the  simplified  permission  bounds.  This  is  particularly  true  for 
appreciating  the  different  between  the  exact  permission  and  the  similar  and  symmetric  permis¬ 
sions.  It  is  crucial  to  understand  that  there  is  some  extra  level  of  quantification  that  is  occurring 
in  the  later  case  that  is  not  occurring  in  the  former  case.  Second,  the  full  system  does  allow  some 
specifications  that  cannot  be  written  in  syntactic  sugar.  For  example,  if  desired,  a  programmer 
could  force  multiple  permissions  to  share  the  same  guaranteed  state.  Still,  due  to  the  large  gain 
in  simplicity,  we  have  chosen  to  implement  the  simplified  syntax  directly  in  our  static  analysis, 
described  in  the  next  section. 


5  Implementation 

In  order  to  better  evaluate  polymorphic  Access  Permissions,  we  have  implemented  a  typestate 
checker  for  the  Java  language  based  on  this  approach.  Our  implementation  is  an  extension  to  the 
Plural  [3]  typestate  checker  for  Java,  which  was  in  turn  based  on  the  original  type  system  presented 
by  Bierhoff  and  Aldrich  [2].  Our  polymorphic  typestate  checker  implements  the  simplified  system 
from  the  previous  section  directly,  and  does  not  allow  abstract  over  each  permission  element. 
All  of  the  specifications  are  written  using  Java  1.5  annotations.  This  presented  a  few  interesting 
challenges. 

The  entire  Plural  implementation,  which  includes  the  polymorphic  variant  described  here,  the 
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source,  and  a  suite  of  tests,  is  available  for  download3.  This  suite  of  tests  includes  Java  versions  of 
all  of  the  examples  presented  in  this  paper,  which  are  correctly  verified. 

The  following  listing  is  a  specification  of  the  Node  class  from  our  earlier  linked  list  exam¬ 
ple,  and  serves  to  illustrate  the  basic  form  of  the  Java  annotations  that  can  legally  be  used  in  our 
implementation: 

©Symmetric (value  =  "p"  , type="T") 

©Invariants (©State (name  =  " alive  ", i nv  =  " uni que ( next)  *  p(item)")) 
class  Node<T>  { 

©ApplyC'p")  Node  next;  T  item; 

©Unique 

©Result Po lyVar ("p") 

T  get(int  i,  int  cur)  {...} 

} 

The  ©Symmetric  annotation  introduces  a  polymorphic  permission  variable  for  the  scope  of 
the  class,  which  must  be  associated  with  a  type.  The  ©Exact  and  ©Similar  annotations  exist 
as  well,  and  the  permissions  introduced  have  the  same  semantics  presented  in  Section  4.  The 
©Invariants  and  ©State  annotations  are  already  a  part  of  the  Plural  typestate  checker,  and  are 
used  to  specify  state  invariants,  but  now  polymorphic  permissions  can  be  used  in  these  invariants. 
The  ©ResultPolyVar  annotation,  along  with  the  ©PolyVar  annotation,  allows  us  to  mention 
these  polymorphic  permissions  in  specifications.  Here  is  how  we  might  instantiate  a  similarly 
specified  LinkedList  class: 

©ResultShare ("Open")  Socket 

getltemFromList (©Unique  ©Apply (" share (Open) " )  LinkedLi st <Socket >  1)  { 
return  1 . get  (®) ; 

} 

The  ©Apply  annotation  applies  the  share  permission  kind  with  a  state  guarantee  of  Open  to  the 
polymorphic  permission  parameter  of  LinkedList.  At  each  application  site,  the  applied  permis¬ 
sion  is  checked  to  ensure  that  it  matches  the  bound  on  the  parameter.  Here,  since  the  permission 
is  share,  it  does.  This  permission  kind  and  guarantee  is  subsequently  substituted  for  p  in  the 
specification  of  the  get  method,  and  the  result  is  that  the  post-condition  of  getltemFromList 
is  satisfied.  In  this  case,  that  means  that  getltemFromList  returns  a  share  permission  with  a 
guarantee  of  Open. 

In  our  current  implementation,  polymorphic  permissions  can  only  be  introduced  at  the  class 
level,  not  at  the  method  level.  Polymorphic  permissions  must  be  instantiated  at  construction  time. 
However,  Java  1.5  annotations  can  not  be  used  on  constructor  expressions.  Therefore  a  very  simple 
unification  algorithm  tracks  the  permissions  that  are  applied  to  any  expression. 

Most  of  the  checking  functionality  piggy-backs  on  top  of  the  existing  Plural  tool.  Within  the 
scope  of  a  polymorphic  variable,  a  simple  flow-based  analysis  tracks  polymorphic  permissions  as 
they  flow  from  specification  to  specification.  This  analysis  treats  polymorphic  permission  vari¬ 
ables  as  being  indivisible  unless  declared  as  symmetric.  As  previously  mentioned,  the  analysis 
also  tracks  the  instantiation  of  each  reference.  At  method  pre-  and  post-conditions,  and  receiver 

3http : //code . google . cora/p/pluralism/ 
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pack  and  unpack  sites,  this  instantiation  information  is  used  to  determine  which  permissions  are 
consumed  and  which  permissions  are  produced.  In  the  case  where  a  polymorphic  permission  is  in¬ 
stantiated  with  an  actual  permission,  our  analysis  substitutes  the  actual  permission  for  the  variable 
in  the  method  specification,  and  then  the  original  Plural  implementation  tracks  whether  or  not  the 
appropriate  permissions  are  available  in  order  to  satisfy  the  method  pre-condition,  and  also  tracks 
the  newly  produced  permissions. 


6  Related  Work 

Existing  approaches  have  contained  some  similar  ideas  to  the  ones  presented  here,  particularly 
with  respect  to  quantification.  In  the  end,  the  novelty  of  our  work  comes  from  the  manner  in  which 
these  ideas  have  been  combined,  and  the  novel  quantification  bounds  that  we  have  used  to  extend 
modular  typestate  checking  to  generic  classes. 

The  original  type  system  upon  which  this  work  was  based  [2]  contains  a  very  limited  form 
of  quantification.  This  system  allows  existential  and  universal  quantification  over  fractions  and 
fraction  functions,  but  only  within  the  scope  of  the  predicate  syntactic  form,  P.  This  quantification 
was  limited  in  many  ways.  Notably,  the  scope  of  the  quantifiers  could  not  extend  over  an  entire 
method  specification,  only  within  a  pre-  or  post-condition.  Our  work  significantly  improves  upon 
the  usefulness  of  the  original  approach  by  extending  the  scope  of  polymorphism  to  the  method  and 
class  level,  by  allowing  state  guarantees  and  assumptions  to  be  abstracted  over,  and  by  allowing 
quantification  classifiers  themselves  to  be  abstracted  over.  This  last  point  is  what  truly  enabled  the 
specification  and  verification  of  collections  that  we  have  seen  in  practice. 

Boyland’s  fractional  permissions  [6]  do  allow  polymorphism,  by  allowing  universal  quantifica¬ 
tion  over  fractions  in  procedure  specifications.  This  allows  programmers  to  write  procedures  that 
return  the  same  fractions  they  were  given,  as  long  as  the  procedure  body  does  not  depend  on  them. 
The  main  difference  is  that  our  work  supports  a  larger  number  of  permission  kinds  (Boyland’s 
work  essentially  supports  unique  and  immutable)  which  means  that  we  must  support  more  inter¬ 
esting  sorts  of  quantification.  For  instance,  Boyland’s  work  does  not  have  an  analogous  notion  of 
polymorphism  over  fraction  and  fraction  function  classifiers,  likely  because  there  are  not  enough 
permission  kinds  to  make  this  a  useful  feature. 

Higher-Order  Separation  Logic  [4]  is  able  to  verify  some  similar  sorts  of  behavioral  properties 
as  our  work.  For  example,  using  standard  logical  quantifiers,  a  function  can  be  defined  that  is 
polymorphic  in  the  state  of  the  objects  that  it  accepts  and  returns.  However,  existing  work  does  not 
allow  polymorphism  over  the  permission  to  heap  locations.  This  is  not  surprising  considering  that 
most  formulations  of  Separation  Logic  have  only  one  “permission.”  That  being  said,  recent  work 
has  extended  fractional  permissions  to  separation  logic  [5].  This  work  does  not  permit  quantifica¬ 
tion  over  fractions  themselves. 

Finally,  Girard’s  original  work  on  Linear  Logic  [9]  allowed  for  quantification  over  linear  facts. 
However,  this  work  was  not  presented  in  the  context  of  managing  program  resources  and  therefore 
it  is  not  clear  how  this  quantification  would  translate  to  permission  accounting  for  polymorphic 
programs. 
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7  Conclusion 


In  this  paper  we  extended  an  existing  type  system,  designed  to  prevent  the  misuse  of  object  proto¬ 
cols,  to  allow  for  polymorphism  over  Access  Permissions,  the  static  predicates  that  track  what  state 
each  object  is  in,  and  how  those  objects  may  be  aliased.  This  results  in  increased  precision  in  the 
specification  of  classes  whose  implementations  do  not  constrain  the  elements  they  contain,  such  as 
a  stack  that  is  equally  capable  of  holding  unique,  open  files  as  shared,  open  sockets.  Our  experi¬ 
ence  has  shown  that  this  expressiveness  is  necessary  in  order  to  be  able  to  specify  commonly  used 
classes  without  false  positives.  While  this  system  was  expressed  in  terms  of  a  low  level  calculus 
where  each  part  of  an  Access  Permission  can  be  abstracted  individually,  we  showed  a  simplified 
syntax  of  our  system  that  can  be  rewritten  in  terms  of  the  underlying  calculus  and  presented  a 
typestate  checker  for  Java  based  on  this  system. 
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